fix(ui-web): say there is no new key instead of sending an empty save - #884

Not a blocker -- from the acceptance pass on head c6e4db7 (merged onto tip be7537c).

Severity of this one finding, not a verdict on the pull request. The blocking findings from this pass are review threads on the changed files; GitHub renders those collapsed, as a file name with no text.

The new local refusal (ui-web/src/features/settings/providers/ProviderDetail.tsx:125) is gated on needsKey(p), which is kindOf(p) === 'key' (Providers.tsx:43), and kindOf maps an endpoint provider to local (Providers.tsx:24). So a connected Azure OpenAI or custom row still sends save_key with only api_base when Update is pressed over an empty or unedited key field. The acceptance pass measured the server refusing that save for both (credential_status lists "an API key" as missing for azure_openai and custom), so those users still get the English refusal this PR replaces for key providers. The path is unchanged from base, so this is a limit on how far the fix reaches rather than a regression; extending the check to endpoint providers, which the server also gates on a key, would cover it.

Checked on the merged tree: npm ci from the tree's own lockfile, npm run type-check clean, and vitest run on ProviderDetail.test.tsx and SetupBodies.test.tsx -- 71 passed. The new gui.settings.providers.key_unchanged key is in i18n/messages.json in en and zh with the {button} placeholder, and ui-tui's generated catalogue carries both.

Covered in deb3d88: the check now takes endpoint-shaped providers (custom, Azure OpenAI, MiniMax CN) as well, since credential_status refuses each of them without a key whether or not an address is sent. Not yet connected, Connect asks for the key first; connected with nothing changed, the same "no new key" line; connected with the address edited, a second line (gui.settings.providers.key_with_base) saying the address is saved together with the key. A save that carries a key goes out as before. Four cases on a custom row in ProviderDetail.test.tsx pin these, and three mutations of the new checks each turn one red.

No blockers in the reviewed scope.

Scope: I reviewed the whole PR at deb3d88df90f (merge base be7537c30), all 5 changed files, including the endpoint commit pushed while my review of c6e4db72478c was in draft. The PR does not touch raven/agent/**. For the key shape it closes the refusal my last summary on #881 listed as checked and not reported.

What I examined: the gates behind model.save_key and model.set_fields for each provider shape the pane draws; needsKey, takesKey, endpointKey and basePlace against what model.options actually sends; the eye flow from #881; the 2026-09-17 and 2026-09-20 designs (the "masked" rule, C10, A8, and the model.set_fields route for an address-only change) against the amended T3.2; and the catalogue pipeline (ui-web imports i18n/messages.json directly, and the TUI copy is generated).

Already filed and now fixed: endpoint-shaped providers skipping the guard is 0xKT's observation of 07:38 UTC. At this head my probe of that path, a connected minimax_cn_api row with Update pressed over the empty field and over an unedited revealed key, records no save and shows key_unchanged.

Findings, both nonblocking:

• Inline on ProviderDetail.tsx:133: for a connected endpoint provider with an edited address and no new key, the page now asks for the key again, although model.set_fields saves the address alone and is the route the 2026-09-17 design gives an address-only change; with the eye open, the stored key sits in the field while the page asks for it. The same note covers bedrock, whose key-less save model.save_key accepts, against the comments and the Risk sentence that say no key-shaped save is.
• Copy, a nit: key_unchanged says "type a new key here", but PaneErr draws it at the foot of the pane, under the models, the Advanced fold and the disconnect row, and scrolls to it, so "here" is not the key field; the same words are in key_set_ph, the field's own placeholder. Both new Chinese strings use a lowercase Latin "key" beside the namespace's other terms for it (the field label's term, and "API Key"); no earlier string under gui.settings.providers.* uses the lowercase form.

Verification at this head:

• vitest run src/features/settings/providers/ProviderDetail.test.tsx: 47 passed
• Each check the PR adds, removed on its own, turns at least one case red: the first commit's two at c6e4db72478c (3 and 1), the endpoint commit's three at this head (1, 2 and 1).
• Full vitest run (ui-web) collects 214 files and 3210 tests. A run under load failed 25 cases in 19 files, none under features/settings/providers/, one of them a file-name gate tripped by my own probe files; with the probes removed, the 19 files re-run alone pass 266 of 266.
• node scripts/gen-i18n.mjs --check (ui-tui): up to date
• For the inline note and the fixed path: model_save_key and model_set_fields on an isolated home per provider shape at this head (the PR does not change the server), and settings-harness cases with endpoint and bedrock rows at this head and at the merge base.
• CI: 20 checks pass, 2 skipped.

Checked and not reported: the guard's address condition, !(b && basePlace), cannot hold for a real row. _accepts_api_key is true for every key-shaped provider, so needsKey implies takesKey and basePlace is null; the condition is load-bearing only for the keyless fixture (kind: 'key', acceptsKey: false), a shape model.options never sends. The fixture predates this PR and the condition mirrors how params is built, so it costs nothing. T3.2 already carries a 2026-10-09 amendment, and the designs' C10 and A8 say only that an unedited key never goes back, which this PR keeps.